The following abbreviations are defined as follows:
ATPCo Airline Tariff Publishing company
GDS Global Distribution System
IATA International Airline Transport Association
OLTA Online Travel Agencies
PNR Passenger Name Record
The following terms are defined as follows.
Fare A set of information giving the price of a travel from a given origin location to a destination location. The Fare may also be referred to as a Fare Entity.
Fare Key Identifying fields of the Fare.
Rule Set of conditions under which a Fare may apply. A Rule may also be referred to as a Rule Entity.
Record1 Fare Application entity: a set of data that complement the Fare and describe the exploitation criteria of the Fare (e.g., the day of the week or the season when the Fare is valid). To one given Record1 may correspond m Fares, each of them inheriting from the exploitation criteria defined in the Record1.
Record2 Rule Category (Seasonality, Minimum stay, etc.)
Record3 Rules Provision: data/value used by the Rule Category (e.g., for the Seasonality Rule Category, a Rule Provision may be ‘Summer’).
FareRec1 Fare with additional Record1 information
The purpose of a Fare quotation is to provide a user with tariffs for certain itineraries. Such tariffs are computed based on Fares and Rules entities as defined above.
As is shown in FIG. 1 a standard Fare quotation provides an informative display context that is accomplished using input data. These input data can be classified as follows:
Itinerary input data (or Itinerary attributes) which are used as search criteria in the Fare quotation and to initiate the process (e.g.: Origin, Destination, Travel Dates, etc.); and Restrictive input data (or Restrictive attributes) which are used as filter criteria in the Fare Quotation process. The Restrictive attributes can be linked to the traveler (e.g., age, corporate, etc.) and/or to the point of sale that is sending the request.
Currently in the airline industry a Fare quotation process/system first retrieves Fares and then applies the Rules in order to perform the Fare quotation. The application of the Rules allows the system to filter the retrieved Fares. The application of the Rules can be decomposed into three main steps.
The first step involves the retrieval of the Fare Applications and performing a merge operation between the Fares and the corresponding Fare Applications. The Fare Application (also referred to as Record1) is the set of data that complement the Fare and describe the exploitation criteria of the Fare (e.g., the day of the week or the season when the Fare is valid). To one given Record1 may correspond m Fares, each of them inheriting from the exploitation criteria defined in the Record1. Hence, the Record1 contains Fare data that have been factorized, and a Fare cannot exist without its corresponding Record1.
The second step involves the application of the Rule Categories (also referred to as Record2). The Rules Categories can be, for example, Seasonality, Minimum stay, etc. The third step involves the application of the Rule Provisions (also referred to as Record3). The Rules Provisions are the data/values used by the Rule Categories (e.g., for the Seasonality Rule Category a Rule Provision may be ‘Summer’).
The Rule Categories and Rule Provisions are application rules that depend on the Pricing context, whereas the Fare Application is valid whatever the context. As an example, assume that Fare Y is valid during all days of the week as per its Fare Application. If the quotation of this Fare is done during the Summer, the Rule Category and associated Rule Provisions will restrict its use to the week-end only. Under certain conditions the Fare applies on a restricted area of its Fare Application. As a result, certain common notions can appear in both the Fare Application and Rule Categories/Provisions.
FIG. 2 shows the main steps/elements of a conventional Fare Quotation and Fare Quotation engine. Starting with Itinerary attributes the Fares are retrieved to obtain Fares. The Fare applications are then retrieved and merged with the retrieved Fares. Rule categories are then applied followed by the application of the Rule provisions (in consideration of the Restrictive attributes). The end result is the outputting of the desired Fare(s).
Currently a problem exists in that airlines have no visibility of the impact on the pricing that results from a filing of a Rule or an update of a Rule. As an example, assume that an airline wants to propose a promotion that is valid for all travel within Europe. The airline files a discount in the Rules, but has no way to check that the discount is available in all markets in Europe.
Moreover, OLTA do not have the possibility to see a global view of the Fares having given Rules characteristics. For example, in the Rules it is possible to define the vendors that are authorized to sell certain Fares. However, if there is no communication of these authorizations then the vendors may not be aware, and thus ignore, of the fact that they are allowed to sell these Fares.